Avoid using unsupported APIs #5057
Conversation
Youssef1313
requested review from
MarcoRossignoli and
Evangelink
as code owners
src/Platform/Microsoft.Testing.Platform/OutputDevice/BrowserOutputDevice.cs
Outdated
Show resolved
Hide resolved
src/Platform/Microsoft.Testing.Platform/OutputDevice/BrowserOutputDevice.cs
Outdated
Show resolved
Hide resolved
src/Platform/Microsoft.Testing.Platform/OutputDevice/BrowserOutputDevice.cs
Outdated
Show resolved
Hide resolved
src/Platform/Microsoft.Testing.Platform/OutputDevice/BrowserOutputDevice.cs
Outdated
Show resolved
Hide resolved
| private void ConsoleWarn(string? message) => _console.WriteLine(message); | ||
|
|
||
| private void ConsoleError(string? message) => _console.WriteLine(message); | ||
|
|
||
| private void ConsoleLog(string? message) => _console.WriteLine(message); |
There was a problem hiding this comment.
Suggestion that doesn't need to be done here. I know nothing about web so maybe that's totally stupid. Is it common to have some kind of prefix for warning/errors in the console? If so we may want to prefix the message
There was a problem hiding this comment.
@Evangelink Usually we would want to use the right API (e.g, console.error and console.warning), which is already done when JSImport is available (net7+).
Ideally, we will want to still always call console.error and console.warning for all TFMs.
@captainsafia Sorry for the ping here, but I can't seem to find the "old" way of doing JS interop as probably all docs are updated to the source-generated attributes. Do you know how to call console.error and console.warning when the source generator isn't available? (Note: we are a netstandard2.0 and net6+ library)
There was a problem hiding this comment.
I don't know off the top of my head but @MackinnonBuck might have ideas here.
|
As discussed offline with @Youssef1313, let's merge as-is and follow up |
No description provided.